With the templates discussed under object copies. It should be possible to move more of the layout java code into otrunk templates. For example the data collector design could consist of separate tool bar, start/stop control, and graph objects. That can be stored in a template. And then the references too it can just be filling in parts of it.

This is something that isn't mentioned in the object copies pages. The current design of object copies has a simple concept of variables. So that a copied object can have a part of itself replaced. Currently on one variable is allowed. A more general design would allow an number of named and typed variables to be defined. And then this would become something like a new object type.

The current design makes something like this possible because the resources are separated from java interfaces. However taking the new object design and generating a schema for it won't work. The move to emf would make this even harder. At least in the way I understand it.

One question is what does student saved state look like in one of these dynamic types. Theoretically any of the values of the template could be changed by the student at run time, so those changes need to be saved somewhere.

One way to say these are not really dynamic types. Instead a object copy is made that is backed by the original object. Then the variables are filled in into the copy. Then the student is given a chance to modify this object. So the students work is saved into the form of the orginal object not the dynamic type.

I think eliminating the java code from this design is important but not crucial. It seems ok to force an author to create the "dynamic type" using the standard object defining mechanism, (which requires java code) but then they can define the mapping of that definition to the actual object with otrunk objects instead of in java code.